home *** CD-ROM | disk | FTP | other *** search
/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / fade into you / being there / Internet Accounting / Draft-brownlee-ipng-acct-req-0 next >
Text File  |  1994-05-31  |  6KB  |  131 lines
  1. INTERNET DRAFT
  2.                         Nevil Brownlee
  3.                         The University of Auckland
  4.                         31 March 1994
  5.                             
  6.         Accounting Requirements for IPng
  7.               <draft-brownlee-ipng-acct-req-00.txt>
  8.  
  9.    This document was submitted to the IETF IPng area in response to
  10.    RFC 1550  Publication of this document does not imply acceptance 
  11.    by the IPng area of any ideas expressed within.  Comments should
  12.    be submitted to the big-internet@munnari.oz.au mailing list.
  13.  
  14.    Distribution of this memo is unlimited.
  15.  
  16.    This document is an Internet Draft.  Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups.  Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet Drafts are draft documents valid for a maximum of six
  22.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  23.    other documents at any time.  It is not appropriate to use Internet
  24.    Drafts as reference material or to cite them other than as a
  25.    ``working draft'' or ``work in progress.''
  26.  
  27.    Please check the 1id-abstracts.txt listing contained in the
  28.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  29.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  30.    current status of any Internet Draft.
  31.  
  32.  
  33.  
  34. Summary
  35.  
  36. This white paper discusses accounting requirements for IPng. It recommends 
  37. that all IPng packets carry accounting tags, which would vary in size. In 
  38. the simplest case a tag would simply be a voucher identifying the party 
  39. responsible for the packet. At other times tags should also carry other 
  40. higher-level accounting information.
  41.  
  42.  
  43. Background
  44.  
  45. The Internet Accounting Model - described in RFC 1272 - specifies how 
  46. accounting information is structured, and how it is collected for use by 
  47. accounting aplications.  The model is very general, with accounting 
  48. variables being defined for various layers of a protocol stack.  The group's 
  49. work has so far concentrated on the lower layers, but the model can be 
  50. extended simply by defining the variables required, e.g. for session and 
  51. application layers. 
  52.  
  53. Brian Carpenter's White Paper on 'transition and other considerations', 21 
  54. Mar 94, suggests that IPng packets should carry authenticated (source, 
  55. destination, transaction) triplets, which could be used for policy-based 
  56. routing and accounting. The following sections explain how the transaction 
  57. field - hereafter called an 'accounting tag' - could be used. 
  58.  
  59. Lower-layer (Transport) Accounting
  60.  
  61. At the lower (network) layers the tag would simply be a voucher. This
  62. means it is an arbitrary string which identifies the party
  63. responsible, i.e. willing to pay for, a packet. It would initially be
  64. set by the host which originates the packet, hence at that stage the
  65. tag would identify the user who sent it.
  66.  
  67. A tag could be changed at various points along a packet's pat. This could 
  68. be done as part of the routing policy processing so as to reflect changes 
  69. of the party responsible over each section of the path. For example: 
  70.  
  71.     user - provider          tag identifies user
  72.     provider A - provider B      tag identifies provider A
  73.  
  74. The tag could be used by accounting meters to identify the party 
  75. responsible for a traffic flow, without having to deduce this using tables 
  76. of rules. This should considerably simplify accounting for transit traffic 
  77. across intermediate networks. 
  78.  
  79.  
  80. Higher-layer (Session and Application) Accounting
  81.  
  82. At higher layers there is a clear need to measure accounting variables and 
  83. communicate them to various points along a packet's path, for example an
  84. application server may wish to inform a client about its usage of 
  85. resources. A tag containing this information could be read by meters at any 
  86. point along the packet's path for charging purposes, and could also be used 
  87. by the client to inform the user of charges incurred.  
  88.  
  89. It would make the collection of accounting data much simpler if this 
  90. information was carried in a standard tag within each packet, rather than 
  91. having different protocols provide this service in differing ways.
  92.  
  93. For 'old' applications which remain unaware of the tag field, a meter could 
  94. be placed at a gateway for the application's host. This 'gateway' meter could 
  95. determine what the application is by watching its streams of packets, then 
  96. set an appropriate value in thir tag fields. 
  97.  
  98.  
  99. Structure of the accounting tag
  100.  
  101. The two uses of tags outlined above must be able to coexist. Since
  102. many - indeed most - of the packets will only carry a voucher, it
  103. seems simplest to keep this as part of the routing tuple (see below).
  104.  
  105. For the application variables, a separate tag seems sensible. This would 
  106. simply contain a list of the variables.  Having two tags in this way 
  107. would keep separate the management of routers and meters.
  108.  
  109. If the encryption/digital signature overhead of the second tag proves
  110. to be too high, it should be possible to combine this with the
  111. voucher.
  112.  
  113. The fine detail of this, or at least the way variables are packed into the 
  114. tags, could be standardised by the Accounting Working Group in due course. 
  115. For the purpose of IPng all that is required is the ability to carry one 
  116. or two variable-size objects in every packet.
  117.  
  118.  
  119. Security Considerations
  120.  
  121. For IPng to provide reliable transport in a hostile environment, routing 
  122. and accounting information, i.e. the (source, dest, network-tag) and 
  123. (application-tag) tuples, must be tamper-proof. Routers and meters which 
  124. need to use the tuples will need to hold appropriate keys for them. Network 
  125. operators will have to plan for this, for example by determining which 
  126. routers need which sets of keys. This will be neccessary in any case for 
  127. reliable policy-based routing, so the extra work required to set up 
  128. accounting meters should be acceptable. 
  129.  
  130.  
  131.